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ABSTRACT 

The  data  dictionary  system  is  an  important  tool  for 
supporting  information  resource  management.  It  facilitates 
the  management  and  control  of  data. 

This  thesis  will  develop  a  relational  model  of  a  data 
dictionaxy  and  implement  it  on  the  ORACLE  relational  data 
base  management  system.  Then,  this  data  dictionary  model 
will  be  implemented  using  the  logic-oriented  Prolog 

j 

language.  The  Prolog  model  of  a  data  dictionary  will  demon¬ 
strate  that  logic  programming  can  be  used  for  relational 
data  base  applications  and  that  it  provides  more  powerful 
dictionary  capabilities  than  the  relational  model. 
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I.  INTRODUCTION 


Data  is  a  resource  to  be  managed.  Data  is  processed  to 
produce  information.  Data  must  be  administered  and 
controlled  to  coordinate  data  usage  in  order  to  produce 
information.  The  transformation  of  data  into  information  is 
the  primary  function  of  an  information  system.  Information 
supports  the  enterprise's  structure  and  generates  its  busi¬ 
ness  processes.  Enterprises  need  to  manage  their  informa¬ 
tion  by  centrally  defining  and  storing  their  data  resource. 

The  data  dictionary  system  (DDS)  plays  an  active  and 
central  role  in  the  management  and  control  of  the  corporate 
data  resource.  It  is  the  repository  of  the  information 
needed  by  the  enterprise.  A  central  source  of  documentation 
helps  improve  communication  between  involved  personnel  and 
offers  improved  system  development. 

The  DDS  has  become  basic  to  all  phases  of  data  adminis¬ 
tration.  The  DDS  is  used  to  satisfy  requirements  for  infor¬ 
mation  resource  management  to  aid  in  database  design  and  to 
provide  the  information  needed  for  the  effective  auditing  of 
the  data.  The  DDS  can  support  many  aspects  of  the  informa¬ 
tion  resource  management  environment  involving  the  manage¬ 
ment  and  use  of  data. 

The  first  part  of  Chapter  2  of  this  thesis  explains  the 
concept  of  data  dictionary  system.  It  explains  metadata, 
metadatabase,  data  dictionary  system,  and  the  functions  of 
the  data  dictionary  system. The  second  part  of  Chapter  2 
surveys  seven  commercially  available  data  dictionary 
systems.  The  general  characteristics  of  these  dictionary 
systems  are  discussed  in  this  survey.  In  Chapter  3,  a  rela¬ 
tional  model  data  dictionary  will  be  developed  and  imple¬ 
mented  on  the  ORACLE  relational  database  management  system. 
Although  a  relational  DBMS  has  many  advantages  over  other 
systems,  it  has  limited  dictionary  capabilities .The  first 


part  of  the  Chapter  4  will  explain  the  general  characteris¬ 
tics  of  expert  systems.  In  the  second  part  of  the  Chapter  4 
a  Prolog  model  of  a  data  dictionary  system  will  be  devel¬ 
oped.  Because  of  the  characteristics  of  Prolog,  the  rules 
about  the  information  resource  management  data  can  be 
defined  more  easily  than  in  the  relational  DBMS  environment. 
By  using  the  Prolog  model  we  can  implement  information 
resource  management  effectively  and  efficiently. 


II.  DATA  DICTIONARY  SYSTEM 


A.  METADATA 

In  order  to  manage  data  as  a  resource,  it  is  essential 
that  data  about  data  be  clearly  specified  by  data  objects. 
These  data  objects  are  called  entities.  In  a  data  base 
environment  the  entities  are  represented  in  the  form  of 
metadata  entities  such  as  data  elements,  records,  files,  or 
data  bases. 

Metadata  entities  are  described  by  means  of  meta¬ 
data,  that  is,  data  about  data.  Metadata  and  user  data  are 
different  from  each  other.  Metadata  is  used  to  describe  the 
characteristics  of  user  data. 

An  example  of  the  metadata  for  a  data  element  in  a  meta¬ 
database  is  given  in  Fig.  2.1  .  In  this  example,  for  the 
data  element  "USNAME",  the  data  dictionary  contains  the 
attributes  like  description,  length,  and  relationship,  but 
not  the  actual  name  of  user.  Thus,  metadata  contains 
descriptive  and  definitional  information  about  the  data. 


Name  of  metadata  entity:  data  element 
Identification:  USNAME 

Description:  user  name  is  entered  as  last  name, 
first  initial,  middle  initial. 

Length/ size:  30  characters,  only  alphanumeric 
characters  allowed. 

Relationship/usage:  this  entity  is  used  in  files  A,  B, 


B.  DICTIONARY  AND  DIRECTORY  METADATA 

The  dictionary  metadata  is  used  by  the  system  users.  In 
contrast,  the  directory  metadata  is  used  by  the  system 
components.  Directory  metadata  provides  information  about 
the  physical  location  of  the  data.  It  shows  how  the  data 
can  be  accessed,  and  it  contains  information  about  the 
internal  representation  of  the  data  entity. 

The  system  which  contains  directory  metadata  is  called 
data  dictionary/  directory  system.  Current  systems  do  not 
separate  dictionary  and  directory  functions.  They  offer 
only  a  partial  independence  between  these  functions. 

C .  METADATABASE 

.A  metadata  database  is  a  collection  of  managed, 
controlled,  and  related  metadata  and  is  referred  to  as  a 
metadatabase.  The  characteristics  of  the  metadatabase  are 
the  same  as  those  of  a  user  database  which  include  data 
sharing,  data  integrity,  and  data  independence.  The  metada¬ 
tabase  is  shared  among  the  user  groups,  processes,  and  auto¬ 
mated  systems  such  as  database  management  systems,  report 
generators ,  and  query  processors . 
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D .  METADATABASE  MANAGEMENT 

The  metadata  needs  a  metadatabase  management  system, 
just  as  the  user  data  needs  a  database  management  system  for 
organization,  access,  and  control.  The  data  dictionary 
system  supports  the  management  and  control  of  the  metadata 

The  DDS  is  a  metadatabase  management  system  which 
provides  user/system  interface  functions,  such  as  query 
processing  and  report  generation  required  for  the  data 
usage.  The  DDS  also  supports  many  administration  and 
control  activities  required  for  metadata  management. 


A  data  dictionary  system  is  a  centralized  repository  of 
data  about  data.  A  DDS  is  used  for  management  and  control 
of  data  resources.  It  is  a  data  base  about  the  data  bases, 
and  users  of  the  data  bases.  The  centralization  of  data 
suggests  that  there  is  enteirprisewide  coordination  and 
control  of  the  metadata.  A  DDS  provides  a  wide  range  of 
facilities  and  capabilities  to  support  metadata  management. 

A  DDS  can  be  implemented  in  different  forms.  The  scope 
of  a  data  dictionary  can  be  narrow.  For  example,  it  can 
consist  of  simple  programs  that  cover  only  the  data  base 
definitions  to  support  a  DBMS.  On  the  other  hand,  it  can  be 
implemented  as  a  very  sophisticated  data  resource  management 
and  control  tool  that  cover  all  the  data  important  to  an 
organization. 

A  DDS  can  use  a  DBMS  in  its  implementation,  that  is,  it 
can  be  a  DBMS -dependent  system,  or  it  can  be  an  independent 
system.  Thus,  it  can  have  a  passive  role  by  producing 
information  about  the  data  base,  or  it  can  force  other  soft¬ 
ware  to  manage  and  control  the  data. 

F.  ACTIVE  AND  PASSIVE  DATA  DICTIONARY  SYSTEMS 

There  are  two  important  implementation  strategies  for 
integrating  the  DDS  into  the  operating  environment  :  an 
active  DDS,  and  a  passive  DDS. 

In  an  active  DDS,  processes  or  system  components  are 
fully  dependent  upon  the  DDS  for  its  metadata,  that  is,  the 
only  source  of  metadata  is  in  the  DDS.  By  contrast,  in  a 
passive  DDS,  processes  and  system  components  are  not  depen¬ 
dent  upon  the  DDS  for  its  metadata.  The  required  metadata 
is  obtained  from  other  resources. 

The  active  DDS  has  several  advantages.  It  eliminates 
redundant  metadata  definition,  insures  consistency  in  the 
metadata,  controls  the  metadata  usage  and  metadata  changes. 


Also,  it  achieves  a  great  data  independence  by  separating 
the  physical  view  from  the  logical  view. 

Although  active  DDS  has  several  advantages,  it  has  some 
drawbacks.  It  introduces  an  overhead  when  binding  time  is 
accomplished  during  execution.  Also,  the  dependency  of 
processing  components  to  the  DDS  causes  bottlenecks  in  some 
systems.  [Ref.  1] 


G.  FUNCTIONS  OF  A  DATA  DICTIONARY  SYSTEM 

The  functions  of  a  typical  DDS  are  the  following  : 

1 .  Maintenance  Function 

This  function  enables  entities,  relationships,  and 
attributes  to  be  added,  modified,  and  deleted  from  the 
dictionary.  The  DDSs  provide  dictionary  maintenance 
commands  to  perform  this  function.  Execution  of  these 
commands  is  subject  to  security  and  restrictions.  There  are 
several  maintenance  methods.  Some  systems  offer  batch  input 
to  enter  the  new  data.  Other  systems  allow  extraction  of 
dictionary  data  from  existing  file  and  database  descrip¬ 
tions  as  well  as  entering  this  data  directly  into  the 
system. 

I 

2 .  Extensibility  Function 

The  extensibility  function  allows  a  user  to  modify 
the  standard  dictionary  schema  to  suit  specific  enterprise 
needs.  The  user  can  add  new  entities  and  attributes  to  the 
dictionary  structure,  and  establish  new  relationships.  Some 
DDSs  offer  a  specific  meta-entity  for  extensibility  feature. 
Others  offer  a  generic  mechanism  to  allow  the  user  to  add 
new  entities  and  attributes. 

3 .  Report  Processor  Function 

Report  processor  function  provides  reports  on  a 
number  of  dictionary  entities.  Report  facilities  are 
invoked  by  means  of  specific  commands.  The  common 

categories  of  reports  are  : 


1.  Reports  of  some  or  all  entities  of  a  given  type. 

2.  Reports  on  all  attributes  for  a  specified  entity 
of  any  type. 

3.  Usage  reports  which  show  either  how  a  given  entity 
is  used  by  other  entities,  or  how  other  entities  use 
a  given  entity. 

4.  A  keyword-in  context  (KWIC)  or  keyword-out-of-context 
(KWOC)  facility  that  is  used  to  search  specified 
attributes  for  a  given  keywords . 

4.  Query  Processor  Function 

This  function  provides  information  about  the  usage 
of  dictionary  entities,  keyword  searches,  and  synonym 
searches.  It  allows  English- like  queries  of  the  DDS.  This 
function  is  most  often  used  in  an  interactive  mode. 


5.  Convert  Functions 


The  convert  functions  scan  application  programs, 
library  files,  and  dictionary  schemata  to  generate  metadata 
from  these  sources  to  be  input  to  the  DDS  maintenance  func¬ 
tion.  There  are  several  options  for  a  convert  function  like 
changing  names,  selecting  lines  to  scan,  selecting  types  of 
transactions . 


Software  Interface  Function 


This  function  provides  metadata  to  other  software 
systems  such  as  DDL  processors  and  compilers.  Software 
systems  access  the  DDS  either  statically  or  dynamically  by 
means  of  software  interfaces.  Static  interfaces  produce 
formatted  statements  for  the  software  packages  or  create 
encoded  control  files  for  their  use.  Dynamic  interfaces 
provide  direct  access  to  other  software  systems  and  use  high 
level  interface  commands. 


7.  Exit  Facility 


The  exit  facility  enables  the  system  user  to  extend 
the  routines  delivered  by  the  DDS  vendor.  For  example,  a 
user  can  code  a  new  security  check  for  accessing  an  entity. 


All  DDSs  do  not  contain  the  exit  facility  because  of 
possible  side  effects  of  user-written  routines. 

8 .  Management  Function 

The  management  function  is  responsible  for  security, 
integrity,  concurrency  control  and  internal  access  for  the 
DDS.  In  DBMS -dependent  dictionary  systems,  some  of  these 
functions  may  be  subsumed  by  the  DBMS  itself.  [Ref.  2] 

H.  SURVEY  OF  DATA  DICTIONARIES 

There  are  several  commercially  available  DDS  packages  in 
the  DDS  marketplace.  Most  of  them  have  introduced  by  the 
DBMS  software  vendors.  In  this  survey,  the  characteristics 
of  the  following  DDSs  will  be  explained  : 

1.  DB/DC  Data  Di ct ionary ( IBM ) . 

2.  Datamanager  (MSP,Inc.). 

3.  Integrated  Data  Dictionary  (IDD)  (Cullinet  Software, 
Inc . ) . 

4.  Extended  Data  Dictionary  (XDD)  (Intel  Systems 
Corporation) . 

5.  Datadictionazry  (Applied  Data  Research). 

6.  UCC  Ten  (University  Computing  ’Company). 

7.  Data  Control  System  (DCS)  (Cincom  Systems,  Inc.). 

The  following  information  has  been  ontained  from  " 
Information  Resource/  Data  Dictionary  Systems  -  Henry  C. 
Lefkovits,  Edgar  H.  Sibley,  Sandra  L.  Lefkovits,  1983,  QED 
Information  Sciences  Inc.,  Wellesley,  Massachusetts  02181  ". 
The  more  information  about  these  dictionary  systems  can  be 
obtained  from  this  reference.  [Ref.  3] 


1.  DB/DC  Data  Dictionary 


Vendor 
Hardware 
Source  language 
Dependent  DBMS 
Entity  names 


International  Business  Machines  (IBM) 
IBM  360,  370,  30xx,  43xx 
Assembler  language. 

IMS  or  DOS  PL/ I. 

Database,  Segment,  Element,  System, 


Extensibility 


Maintenance 


Reports  and  queries 


Status  facility 


Security  facility 


Job,  Program,  Module,  Transaction, 
PSB,  PCB,  SYSDEF. 

:  New  entity-types ,  relationship- types , 
and  attribute- types  can  be  defined. 
Dictionary  schema  has  Extensibility 
Control  Information  entity-types  : 
CATEGORY,  RELTYPE,  and  ATTRTYPE. 

:  Three  different  maintenance  ways  : 

1 .  Keyword  driven  commands . 

2.  3270  Interactive  Forms. 

3.  The  Batch  Forms  Input  facility. 

:  Reporting  commands  : 

REPORT,  SCAN,  PUNCH. 

Reports  : 

1.  Entity- Specific  reports. 

2.  Display  form  equivalent  reports. 

3.  Indirect  entity  reference  reports. 

4.  Glossary  reports. 

5.  GUIDE  reports. 

:  Every  entity  have  a  status  which  is 
being  expressed  by  a  status  code. 
Status  codes  : 

Test,  Production,  Installed  and 
user-defined. 

:  Access  characteristics  can  be 
assigned  as  follows  : 

1.  Status. 

2.  Entity- type. 

3.  SIGN- ON  command. 

DDUSER  entity- type  is  used  to 
establish  authorized  users. 

DBD-IN,  PSB-IN,  COBOL-IN,  PLI-IN 
commands  are  used  for  reading  these 
descriptions  and  creating  dictionary 


Bridge  facility 


2 .  Datamanager 


entities  and  relationships 
corresponding  to  them. 


Vendor 

Hardware 

Source  language 
Dependent  DBMS 
Entity-names 

Extensibility: 


Maintenance 


Reports  and  queries 


Status  facility 


Management  Systems  and  Programming. 
IBM  360,  370,  30xx,  43xx,  and  plug 
compatible  machines. 

Assembler  language. 

Independent . 

File,  Group,  Item,  System,  Program, 
Module. 

By  using  User  Defined  Syntax  facility 
user  can  define  extensibility  entity- 
types  and  attribute  types. 

A  number  of  commands  are  available 
for  adding  new  entities,  modifying 
and  deleting  them.  These  commands 
can  be  executed  either  on-line  or 
in  batch  mode.  Also  there  are 
commands  for  manipulating  definitions 
of  entities. 

The  report  commands  :  Print,  List, 
Report,  Glossary,  Bulk  Print,  Bulk 
Report,  Switch,  Skip,  Space,  Text. 

The  query  commands  : 

What,  Which,  Whose,  Who,  Does,  Show. 
Both  sets  of  commands  can  be  used  in 
both  batch  and  interactive  modes  and 
they  contain  facilities  for  selecting 
categories  of  entities. 

The  dictionary  administrator  can 
define  up  to  256  statuses,  each  one 
of  which  has  a  name.  There  exist  two 
types  of  statuses  :  non- frozen  and 
frozen. 


18 


Security  facility 


:  For  entering  the  system  a  password 
is  supplied  by  the  AUTHORITY  command. 
Individual  entities  can  be  assigned 
levels  of  protection  by  the  PROTECT 
command.  A  user  can  also  be  assigned 
a  specific  security  level.  Also,  the 
dictionary  itself  can  be  assigned  an 
insertion  security  level  and 
protection  security  level. 

Bridge  facility  :  Three  bridge  facilities  available  : 

1.  The  User  Interface  facility. 

2.  The  Source  Language  Generation 
Facility. 

3.  Interfaces  to  DBMSs  and  the  MARK 
IV  File  Management  System. 


Integrated  Data  Dictionai 


Vendor  :  Cullinet  Software,  Inc. 

Hardware  :  IBM  360,  370,  30xx,  43xx. 

Source  language  :  Assembler  language. 

Dependent  DBMS  :  IDMS. 

Extensibility  ;  System  supports  a  full  range  of 

schema  extensibility  features  that 
allow  to  perceive  and  use  additional 
entity- types ,  relationship-types ,  and 
attribute- types .  There  are  two 
mechanisms  which  are  used  for 
extensibility  : 

1.  The  CLASS /ATTRIBUTE  declaration. 

2.  The  definition  of  relational  keys. 
:  SET  OPTIONS  command  is  used  for 

control  of  the  default  processing 
options.  DDDL  statements  may  be 


Maintenance 


executed  either  in  a  batch  or 
on-line.  For  on-line  usage  an  option 
exists  for  either  full  screen  or 
line  mode  entry  of  statements.  Three 
main  maintenance  commands  are  : 

ADD,  MODIFY,  DELETE. 

Reports  and  queries  :  Four  different  ways  for  data 

retrieving  : 

1.  Standard  reports  of  the  DDR 
(Dictionary/Directory  Reporter) . 

2.  Facilities  of  the  CULPRIT  system. 

3.  Using  DISPLAY/PUNCH  command. 

4.  Using  OLQ,  accessing  QFILEs . 

The  specific  DDR  reports  : 

1.  Detail  reports. 

2.  Key  reports. 

3.  Summary  reports. 

4.  Cross-reference  reports. 

5.  Special  purpose  reports. 


y 


Status  facility 


Security  facility 


:  VERSION  mechanism  is  the  major  way 
to  provide  different  environments  for 
development,  test,  etc.  By  using 
VERSION  clause,  a  number  appended  to 
the  entity  name. 

:  This  facility  consists  of  both  global 
and  local  mechanism.  The  dictionary 
administrator  can  establish  security 
for  the  entity- types  and  the 
following  functionality  : 

1.  CLASS  and  ATTRIBUTE  security. 

2.  LOAD  MODULE  security. 

3.  IDMS  security. 

4.  IDMS-DC  security. 

5.  IDD  security. 


Ml 


Bridge  facility 


4.  Pat adict ionary 

Vendor  : 
Hardware  : 
Source  language  : 
Dependent  DBMS  : 
Entity-names  : 


Extensibility 

Maintenance 


Reports  and  queries  : 


Status  facility 


Security  facility 


6.  OLQ  security. 

7.  CULPRIT  security. 

There  exist  bridges  from  IDMS-DB/DC 
to  IDD  as  well  as  in  the  other 
direction,  from  IDD  to  IDMS-DB/DC. 


Applied  Data  Research  (ADR) . 

IBM  360,  370,  30xx,  43xx. 

Assembler  language. 

DATACOM/DB. 

Element,  Key,  Field,  Record,  File, 
Report,  Area,  Database,  Dataview, 
System,  Program,  Module,  Job,  Step, 
Library,  Member,  Node,  Authorization, 
Panel,  Person. 

New  entityrtypes ,  relationship-types , 
and  attribute-types  can  be  introduced 
Two  primary  maintenance  ways  : 

1.  On-line  maintenance  facility. 

2.  Batch  execution  transactions. 

The  Input  Creation  Facility  analyzes 
COBOL  record  descriptions  and  creates 
corresponding  entities. 

System  has  two  facilities  to  extract 
data  from  the  dictionary  : 

1.  The  Batch  Reporting  facility. 

2.  The  On-line  Maintenance  facility. 
Two  status  mechanisms  : 

1.  An  entity  may  be  assigned  a 
version  number. 

2.  Every  entity  has  an  attribute  of 
type  STATUS. 

Two  security  mechanisms  : 


1.  The  use  of  Passwords. 

2.  The  use  of  Locks  and  Override 


Codes . 

Additionally,  through  the  use  of 
on-line  interface  a  user  can  be 
assigned  a  password,  and  an 
authorization  level. 

Bridge  facility  :  Two  bridge  facilities  : 

1.  The  Service  facility. 

2.  The  Source  Language  Generation 
facility. 


5 .  Extended  Data  Dictionary 


Vendor 
Hardware 
Source  language 
Dependent  DBMS 
Entity  names 


Extensibility 


Maintenance 


Reports  and  queries 


:  Intel  Systems  Corporation. 

:  IBM  360,  370,  30xx,43xx. 

:  Assembler  language. 

;  System  2000. 

:  Data  Base,  File,  Work  Area,  Schema, 
Record,  Subschema  Record,  File 
Record,  Work  Structure,  Item,  User 
Application,  Work  Unit,  Program. 

;  New  entity-types ,  attribute-types , 
or  relationship- types  can  be  defined. 
The  master  password  is  required  for 
this  process. 

:  Three  maintenance  ways  : 

1.  Use  of  the  XDD  update  and  utility 
strings . 

2.  Use  of  SCF  (Self-Contained 
Facility) . 

3.  Use  of  QueX  facility  of  System 

2000. 

:  The  Report  Generation  Procedures 
provide  five  reports  :  CAT,  DES, 
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Status  facility 


Security  facility 


Bridge  facility 


EXC,  EXS,  and  EXl.  Also,  the  PRODUCE 
command  provides  explosion  and  impact 
reports . 

:  The  status  facility  consists  of  the 
use  of  multiple  versions  for  entities 
of  all  types.  Every  version  of  an 
entity  has  a  unique  status.  Multiple 
versions  can  exist  which  have  the 
same  status. 

:  A  Master  Password  can  be  selected. 
This  password  allows  secondary 
passwords  to  be  assigned  to  the 
users.  Each  such  password  has 
associated  authorities  that  control 
dictionary  operations. 

:  Two  bridge  facilities  : 

1.  The  dictionary  mat  be  preloaded 
using  COBOL  and  COBOL  PLEX  program 
Data  Collection  facilities  to 
extract  meta  data  from  the  COBOL 
or  COBOL  PLEX  programs . 

2.  The  XDD  COBOL  Generation  Bridge 
may  be  used  to  distribute 
structures  and  logical  views  to 
COBOL  or  COBOL  PLEX  programs . 


6.  Ten 

Vendor 
Hardware 
Source  language 
Dependent  DBMS 
Entity  names 


:  University  Computing  Company. 

:  IBM  360,  370,  30xx,  43xx. 

:  90  %  COBOL,  10  %  Assembler  language. 
:  IMS  HIDAM  databases. 

:  Field,  List,  Segment,  Data,  Group, 
Set,  File/Data  Base,  Transaction, 
Module,  Program,  Job  Application, 
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Program  Specification  Block  (FSB), 

ID,  and  23  more  communication 
oriented,  message  oriented,  format 
oriented  and  ADF  oriented 
entity- types . 

Extensibility  :  None. 

Maintenance  :  Three  maintenance  interfaces  : 

1.  Transactions  that  are  submitted 
in  one  of  the  following  modes  : 
On-line  at  terminal,  On-line 
Queue,  Batch  Queue,  Batch  DBA. 

2.  Input  to  the  dictionary  using 
preformatted  screens  via  3270 
terminals . 

3 .  Fixed  format  input  for  adding 
entities  and  certain 
relationships . 

Reports  and  queries  :  Three  types  of  reports  : 

1.  Entity  reports. 

2.  Text  reports. 

3.  Keyword  reports. 

Status  facility  :  System  provides  Text  and  Production 

status  with  255  sides. 

Security  facility  :  System  contains  a  security  user  exit. 

This  exit  is  used  for  the  password 
protection  of  the  DSTRUCTURE  and 
DABSOLUTE  commands.  IMS  security 
facilities  are  also  available. 

Bridge  facility  :  System  contains  facilities  whereby 

the  contents  of  the  dictionary  can 
be  used  to  generate  source  statements 
that  can  be  used  by  other  software 
processors.  These  actions  can  be 
invoked  through  the  GENERATE 
transaction. 


7.  Data  Control  System  (DCS) 

Vendor  :  Cincom  Systems,  Inc. 

Hardware  :  IBM  370,  30xx,  43xx. 

Source  language  :  COBOL  and  MANTIS . 

Entity  names  :  Element,  File,  Database,  Report, 

Source  Document,  Transaction,  User 
Application  System,  Program. 
Extensibility  :  None. 

Maintenance  :  Entities  and  relationships  are  added, 

modified,  and  deleted  by  the  use  of 
predefined  screens.  The  types  of 
screens  are  : 

1.  Facility  Selection  Menu . 

2.  Entity  Screens. 

3.  Relationship  Screens. 

4.  Table  Definition  Screens. 

5 .  Mini  Menus . 

Reports  and  queries  :  System  provides  two  facilities  : 

1.  The  Interactive  Screen  Interface 
which  can  be  used  to  display 
information  about  entities  and 
relationships . 

2.  The  Batch  Reporting  facility 
which  can  be  used  to  produce 
preformatted  reports. 

Status  facility  :  None. 

Security  facility  :  System  contains  a  special 

identification  of  a  user  called  the 
Master  User.  This  Master  User  assigns 
passwords  to  other  users. 

Bridge  facility  ;  The  DCS  Generation  Facility  which 

consists  of  CSIDBIOl  and  CSIDBI02 
programs,  can  be  used  to  control 
database  access  to  TOTAL  databases. 


III.  RELATIONAL  DICTIONARY  MODEL 
A.  THE  RELATIONAL  MODEL 

The  relational  model  views  a  logical  data  base  as  a 
collection  of  tables.  These  tables  are  two-dimensional  and 
are  called  relations.  Relations  contain  single-valued 
entries  but  no  repeating  groups  or  arrays.  The  columns  of  a 
relation  are  called  attributes,  and  the  rows  are  called 
tuples.  Each  column  contains  the  same  kind  of  data 
(e.g. :dates) ,  but  the  entries  in  rows  are  not  identical. 
The  rows  and  columns  can  be  ordered  in  any  sequence  without 
affecting  the  information  content.  [Ref.  4] 

The  logical  relationships  are  inherent  in  the  data  with 
the  relational  model.  Two  tuples  can  have  a  relationship  if 
they  have  two  attributes  that  arise  from  the  same  domain. 
Users  can  access  and  combine  data  using  data  values. 

The  relational  data  base  approach  provides  many  advan¬ 
tages  in  ease  of  use  and  simplicity,  data  independence,  user 
friendliness,  flexibility,  data  base  processing  power,  and 
security  controls.  Also,  it  provides  a  good  theoretical 

I 

foundation  grounded  in  the  mathematical  theory  of  relations. 

The  relations  are  easy  to  understand  by  users. 
Relationships  between  relations  are  easily  expressed.  With 
relations,  a  high  degree  of  data  independence  can  be 
achieved.  A  wide  variety  of  relations  can  be  derived  easily 
by  using  algebraic  operations  to  satisfy  different  user 
needs.  By  using  these  algebraic  operations,  users  can  be 
constrained  to  specific  instances  of  relations  and 
attributes . 
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B.  OVERVIEW  OF  ORACLE  SYSTEM 


The  ORACLE  relational  data  base  management  system  is  a 
computer  program  that  manages  data.  Users  access  data  via 
the  SQL  nonprocedural  data  sublanguage  which  is  a  structured 
query  language  with  English  keywords . 

An  ORACLE  data  base  consists  of  tables  which  in  turn 
consist  of  columns  and  rows.  A  row  is  made  up  of  fields 
which  contain  data  values.  An  example  of  a  table  is  given 
in  Fig.  3.1  . 


EMPLOYEE 


EMPNO 

ENAME 

JOB 

20 

THOMAS 

SALESMAN 

32 

JOHNSON 

ANALYST 

35 

MARTIN 

MANAGER 

Figure  3.1  An  ORACLE  Table. 

A  user  can  create  tables  via  the  SQL  Data  Definition 
Language  commands.  The  CREATE  TABLE  command  is  used  to 
create  a  new  table.  The  column  names  and  the  data  types  of 
the  columns  are  specified  for  each  table  created.  The  DROP 
TABLE  statement  deletes  a  table  from  the  data  base  schema. 

After  a  table  is  created,  data  can  be  entered  into  the 
table  via  an  INSERT  command.  Users  can  remove  a  row  from  a 
table  using  the  DELETE  command.  The  UPDATE  command  allows  a 
user  to  modify  a  field  in  a  row  of  a  table. 

The  most  common  operation  in  ORACLE  is  to  retrieve  data 
from  tables  by  means  of  queries.  The  SELECT  command  is  used 


for  this  purpose.  By  using  this  command,  we  can  select  all 
the  columns  or  specific  columns  from  a  table.  We  can  also 
control  the  order  columns  are  displayed,  and  prevent  the 
selection  of  duplicate  rows.  The  syntax  of  SELECT  command 
as  following  : 

SELECT  some  columns 

FROM  some  tables 

WHERE  certain  conditions  are  met. 

SQL  provides  a  powerful  join  operator  as  part  of  the 
SELECT  command.  Two  or  more  tables  can  be  merged  on  the 
basis  of  common  fields,  resulting  in  a  single  table.  We  can 
list  the  tables  to  be  joined  in  the  FROM  clause  and  the 
relationships  between  the  tables  in  the  WHERE  clause. 
[Ref.  5] 

C.  A  RELATIONAL  DATA  DICTIONARY  MODEL 

A  relational  data  dictionary  (RDD)  model  was  developed 
and  implemented  using  ORACLE.  This  RDD  system  runs  on 
VAX-VMS  11/780  computer. 

The  National  Bureau  of  Standards  (NBS)  has  developed 
dictionary  standards  which  capture  the  common  features  of 
systems  such  as  extensibility,  maintenance,  and  report 
processing.  The  dictionary  system- standard  schema  has 
specific  entity-types ,  relationship- types ,  and  attribute 
types  which  are  developed  by  the  NBS.  The  system- standard 
schema  constitutes  the  core  of  the  logical  structure  of  this 
dictionary.  The  entity-types ,  attribute- types ,  and 
relationship-types  are  as  shown  in  Tables  I,  II,  and  III. 

1.  Description  of  Entity- types 

1.  USER,  describes  a  person  or  an  organization  that  uses 
the  DDS. 

2.  SYSTEM,  describes  a  collection  of  programs  and/or 
modules  associated  with  a  major  function  of  the 
enterprise . 
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TABLE  I 


ENTITY-TYPES  OF  NBS  SYSTEM- STANDARD  SCHEMA 


USER 

SYSTEM 

PROGRAM 

MODULE 

ITTT  IT 

DOCUMENT 

RECORD 

ELEMENT 

BIT- STRING 

CHARACTER- STRING 

FIXED- POINT 

FLOAT 


TABLE  II 


RELATIONSHIP -TYPES  OF  NBS  SYSTEM- STANDARD  SCHEMA 


CONTAINS 
PROCESSES 
RESPONSIBLE  FOR 
RUNS 
GOES  TO 
DERIVED  FROM 
CALLS  - 
REPRESENTED  AS 
STANDARD  FOR 
HAS  SORT-KEY 
HAS-ACCESS  KEY 


PROGRAM,  represents  information  about  a  collection  of 
executable  code. 

MODULE,  describes  the  parts  of  programs  which  are 
logically  associated  with  each  other. 

FILE,  describes  collections  of  records. 

DOCUMENT,  describes  instances  of  data  to  document  to  the 


user. 


RECORD,  describes  instances  of  logically  associated 
data. 


TABLE  III 

ATTRIBUTE -TYPES  OF  NBS  SYSTEM- STANDARD  SCHEMA 


ADDED  BY 
ALLOWABLE  RANGE 
ALLOWABLE-VALUE 
CLASSIFICATION 
CODE  LIST  LOCATION 
COMMENTS  - 
DATA  CLASS 
DESCRIPTION 
DURATION  TYPE 
DURATION-VALUE 
ENTITY  NAME 
ENTITY-TYPE 

LAST  MODIFICATION  DATE 
LAST-MODIFIED  BY  - 
LOCATION 

NUMBER  OF  LINES  OF  CODE 
NUMBER-OF“MODIFTCATI ON S 
NUMBER-OF-RECORDS 
RECORD-CATEGORY 
SECURITY 


8.  ELEMENT,  describes  an  instance  of  data. 

9.  BIT_STRING,  describes  a  string  of  binary  codes. 

10.  CHARACTER_STRING ,  describes  a  string  of  characters. 

11.  FIXED_POINT,  describes  the  representation  of  numeric 
'  values. 

12.  FLOAT,  describes  the  representation  of  approximate 
numeric  values . 

2.  Description  of  Attribute- types 

1.  ADDED_BY,  describes  the  person  who  inserts  data  into  a 
relation. 

2.  ALLOWABLE_RANGE ,  describes  the  allowable  range  of  a  data 
element . 

3.  ALLOWABLE_VALUE ,  describes  the  allowable  value  for  a 
data  element. 

4.  CLASSIFICATION,  describes  the  area  of  responsibility  or 
interest  of  an  entity. 

5.  CODE_LIST_LOCATION,  describes  the  hardware  location  of 
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codes  of  a  program  or  module. 

6.  COMMENTS,  gives  information  about  the  characteristics  of 
an  entity. 

7.  DATA_CLASS,  describes  the  class  of  a  data  element. 

8.  DATE_ADDED,  describes  the  insertion  date  of  a  data 
element  into  the  data  base. 

9.  DURATION_TYPE ,  describes  the  type  of  duration  of  a 
process . 

10.  DURATION_VALUE ,  describes  the  duration  value  required 
for  a  process. 

11.  ENTITY_NAME,  represents  the  name  of  an  entity  in  the 
data  base. 

12.  ENTITY_TYPE,  describes  the  type  of  an  entity  in  the 
data  base. 

13.  LAST_MODIFICATION_DATE,  describes  the  last  modification 
date  of  a  data  element  in  the  data  base. 

14.  LAST_MODIFIED_BY ,  describes  the  user  who  makes  the  last 
modification  to  a  data  element. 

15.  LOCATION,  describes  the  hardware  location  of  data  in 
the  data  base. 

16.  NUMBER_0F_LINES_0F_C0DE ,  represents  the  number  of  codes 
'  of  a  program  or  a  module. 

17.  NUMBER_OF_MODIFICATIONS,  represents  the  number  of 
modifications  of  a  data  element. 

18.  NlJMBER_OF_RECORDS ,  represents  the  number  of  records  of 
a  file. 

19.  RECORD_CATEGORY ,  describes  the  category  of  a  record  in 
a  file. 

20.  SECURITY,  describes  the  security  class  of  an  entity  for 
explaining  the  authority  level  of  a  user  to  use  it. 


3.  Description  of  Relationship- types 


1.  CONTAINS,  describes  a  relation  where  an  entity- type 
contains  other  entity-types . 

2.  PROCESSES,  describes  a  relation  where  an  entity- type 
processes  other  entity- type. 

3.  RESPONSIBLE_FOR,  describes  the  responsibility  of  a  user 
to  process  a  DDS  element. 

4.  RUNS,  describes  an  association  between  user  and  system 
elements . 

5.  GOES_TO,  describes  a  relation  where  a  process  transfers 
control  to  another  one. 

6.  DERIVED_FROM ,  describes  a  relation  where  an  entity  is 
derived  from  another  one. 

7.  CALLS,  describes  a  relation  where  an  entity  calls 
another  one. 

8.  REPRESENTED_AS ,  describes  the  entities  that  document  a 
data  element. 

9.  STANDARD_FOR,  describes  the  standard  elements  used  to 
describe  an  element. 

10.  HAS_SORT_KEY ,  describes  the  sort  key  element  of  a  file. 

11.  HAS_ACCESS_KEY,  describes  the  access  key  element  of  a 
file. 

4.  The  Relations  of  Dictionary 

The  dictionary  has  several  different  relations.  The 

general  of  these  relations  is  as  follows  : 

USER_X  (  user_name,  description,  classification,  date_ 

added , added_by ,  last_modif ication_date ,  last_ 
modified_by,  number_of_modif ications ,  location, 
comments,  security  ) 

SYSTEM  (  systemjiame ,  description,  classification,  date_ 
added,  added_by,  last_modification_date ,  last_ 
modified_by,  number_of_modif ications ,  location, 
duration_value,  duration_type ,  comments,  security) 
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PROGRAM  (  programjiame ,  description,  number_of_lines_of_ 

code,  classification,  date_added,  added_by,  last_ 
modification_date,  last_modified_by ,  number_of_ 
modifications,  location,  duration_value,  duration 
_type,  comments,  security  ) 

MODULE  (  modulejnama,  description,  classification,  date_ 
added,  added_by,  last_modif ication_date ,  last_ 
modified_by,  location,  number_of_lines_of_code , 
number_of_modif ications ,  comments,  security  ) 

FILE_X  (  filejname,  description,  classification,  date_ 

added,  addedby,  last_modif ication_date ,  last_ 
modified_by,  location,  number_of_modifications , 
number_of_records ,  comments,  security  ) 

DOCUMENT  (  document jname ,  description,  classification, 

date_added,  added_by,  last_modif ication_date , 
last_modified_by ,  location,  number_of_ 
modifications,  comments,  security  ) 

RECORD  (  recordjtame,  description,  classification,  date_ 
added,  added_by,  last_modif ication_date ,  last_ 
modified_by,  number_of_modif ications ,  record_ 
category,  comments,  security  ) 

ELEMENT  (  elementjname,  description,  classification,  date_ 
added,  added_by,  last_modification_date ,  last_ 
raodified_by,  number_of_modif ications ,  allowable_ 
range,  allowable_value ,  comments,  code_list_ 
location,  data_class,  security  ) 

CONTAINS  (  entityjnamel ,  entityjtypel ,  entity_naae2j  entity 
JtypeZ  ) 

PROCESSES  (  entityjnamel ,  entityjtypel ,  entity  jname  2, 
entity  JtypeZ  ) 


.-•VO  -*•  k***-**'  *'*v*k'^ 


RESPONSIBLE_FOR  (  entityjnamel ,  entity _ty pel ,  entity _name2, 

entity _type2  ) 

RUNS  (  ent ity jnamel ,  entity _ty pel ,  ent ity _name2 ,  entity 
_type2  ) 

GOES_TO  (  ent ity jnamel ,  entity _typel ,  ent ity _name2 , 
entity _type2  ) 

DERIVED_FROM  (  entity _namel ,  entity _typel ,  entity _name2, 
entity _type2  ) 

CALLS  (  entity _namel ,  entity J:ypel ,  ent ity _name2 , 
entity_type2  ) 

REPRESENTED_AS  (  ent  ity _namel ,  entity _typel ,  ent  ity _name2 

entity _type2  ) 

STANDARD_FOR  (  entity jnamel ,  ent  ity _typel ,  ent  ity jname2 , 
entity _type2  ) 

HAS_ACCESS_KEY  (  entity-namel ,  entity _typel ,  ent  ity _name2 , 

entity _type2  ) 

HAS_SORT_KEY  (  entity jiamel ,  entityjtypel  ,entity_name2, 
entity _type2  ) 

There  are  two  special  relations  in  the  dictionary 
schema  :  ALIAS  and  CATEGORY.  The  ALIAS  relation  is  used  to 
record  synonyms .  Synonyms  are  two  or  more  names  for  the 
same  data  item.  In  an  enterprise  every  department  can  use 
different  names  for  the  same  data  item  in  the  data  base.  In 
this  case,  the  synonyms  are  recorded  as  aliases.  The  ALIAS 
relation  in  the  data  dictionary  is  defined  as  : 

ALIAS  (  entityjname,  entity _type ,  alias jiame  ) 

The  CATEGORY  relationship  provides  a  key  word  in 
context  (KWIC)  capability  which  allows  different  entities  to 
be  arbitrarily  categorized  by  user-defined  terms.  For 
example  it  may  be  desirable  to  classify  certain  files, 


programs,  reports,  users,  etc.  as  being  PERSONNEL- related. 
This  can  be  done  via  CATEGORY  by  associating  each  such 
entity  with  the  PERSONNEL  category.  The  format  of  CATEGORY 
relation  is  defined  as  : 

CATEGORY  (  entityjiame,  entity _type,  category jname  ) 

The  dictionary  model  has  a  specific  relationship  by 
which  we  can  represent  the  dictionary  entities  and  the 
specific  relationships  in  which  they  participate.  This 
relationship  makes  the  dictionary  model  self-descriptive. 
Thus,  it  can  describe  its  schema  structure.  The  format  of 
this  relationship  as  following  : 

RELATIONSHIP  (  entity _namel ,  entity _ty pel ,  entity _name2, 

entity _typeZ,  relation  ) 

Another  type  of  relationship  of  the  dictionary  model 
is  ENTITY  by  which  we  represent  the  entity_types  such  as 
’SYSTEM',  'FILE*,  etc.  .  The  format  of  this  relationship  as 
following  : 

ENTITY  (  entityjiame,  description,  classification,  date_ 
added,  added_by,  last_modification_date,  last_ 
modified_by,  number_of_modif ications ,  location, 
comments,  security  ) 

D.  RELATIONSHIPS  BETWEEN  ENTITY- TYPES 

The  pairs  of  entity-types  belong  to  a  specific  relation¬ 
ship  are  as  shown  in  Table  IV  (entity-typel  and  entity- 
type2  are  both  assumed  to  be  'ENTITY'  and  are  omitted  for 
the  sake  of  clarity  ) . 
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RELATIONSHIPS 

TABLE  IV 

BETWEEN  ENTITY- TYPES 

CONTAINS  : 

PROCESSES  : 

SYSTEM,  SYSTEM 

USER,  FILE 

SYSTEM,  PROGRAM 

USER  DOCUMENT 

SYSTEM,  MODULE 

USER,  RECORD 

PROGRAM,  PROGRAM 

USER,  ELEMENT 

PROGRAM,  MODULE 

SYSTEM,  FILE 

MODULE,  MODULE 

SYSTEM,  DOCUMENT 

FILE,  FILE 

SYSTEM,  RECORD 

FILE,  DOCUMENT 

SYSTEM,  ELEMENT 

FILE,  RECORD 

PROGRAM,  FILE 

FILE,  ELEMENT 

PROGRAM,  DOCUMENT 

DOCUMENT,  DOCUMENT 

PROGRAM,  RECORD 

DOCUMENT,  RECORD 

PROGRAM,  ELEMENT 

DOCUMENT,  ELEMENT 

MODULE,  FILE 

RECORD,  RECORD 

MODULE,  DOCUMENT 

RECORD,  ELEMENT 

MODULE,  RECORD 

ELEMENT,  ELEMENT 

MODULE,  ELEMENT 

RESPONSIBLE_FOR  : 

RUNS  : 

USER,  FILE 

USER,  SYSTEM 

USER,  DOCUMENT 

USER,  PROGRAM 

USER,  RECORD 

user!  module 

user!  element 

SYSTEM,  FILE 

SYSTEM,  DOCUMENT 

GOES  TO  : 

SYSTEM  RECORD 

SYSTEM  ELEMENT 
PROGRAM,  FILE 

SYSTEM,  SYSTEM 

PROGRAM  DOCUMENT 

PROGRAM,  PROGRAM 

PROGRAM,  RECORD 

MODULE,  MODULE 

PROGRAM  ELEMENT 
<  MODULE ,  FILE 

MODULE,  DOCUMENT 

DERIVED  FROM  : 

MODULE,  RECORD 

....  . . . 

MODULE,  ELEMENT 

DOCUMENT,  FILE 

CALLS  : 

DOCUMENT,  DOCUMENT 

DOCUMENT,  RECORD 

ELEMENT,  FILE 

ELEMENT,  DOCUMENT 

PROGRAM,  PROGRAM 

ELEMENT,  RECORD 

PROGRAM,  MODULE 

ELEMENT.  ELEMENT 

MODULE,  MODULE 

FILE,  DOCUMENT 

STANDARD_FOR  : 
ELEMENT,  ELEMENT 

file!  file 

RECORD,  DOCUMENT 

REPRESENTED_AS  : 

HAS  SORT  KEY  & 

ELEMENT,  BIT  STRING 

ELEMENT,  CHARACTER  STRING 

HAS-ACCESS  KEY  : 

ELEMENT,  FIXED  POINT 

““ 

ELEMENT,  FLCAT" 

FILE,  ELEMENT 

msm 
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Figure  3.2  Bachman  Diagram  of  entity_types . 


The  relationships  between  the  entity-types  are  shown  in 
Fig.  3.2  .  In  this  diagram,  we  denote  the  relationship 
one-to-one  by  a  single-  headed  arrow  ( - >  ),  and  the  rela¬ 
tionship  one-to-many  by  a  double-headed  arrow  (  - >>  ). 

The  implementation  of  data  dictionary  model  using  ORACLE 
has  some  shortcomings.  We  can  represent  entity- types ,  and 
relationships  between  these  entities  easily.  But,  we  also 
need  rules  about  data. 
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ORACLE  implementation  is  not  capable  of  defining  rules.  We 
can  only  implement  immediate  data  with  ORACLE. 

E.  EXAMPLES  OF  QUERIES 

By  using  SQL  commands,  we  can  represent  several 
different  queries.  These  queries  are  two  types  :  queries 
concerning  meta-entities  and  those  concerning  instances  of 
entities.  There  are  several  advantages  of  having  the  meta¬ 
entity  information.  The  quality  of  metadata  should  be  moni¬ 
tored  by  defining  and  inserting  integrity  checks.  We  can  do 
these  checking  by  means  of  queries  concerning  meta-entities. 
These  queries  also  give  information  about  the  system- 
standard  schema  of  the  dictionary  system.  That  is,  we  can 
describe  the  entity- types ,  attribute- types ,  and 
relationship- types  of  the  dictionary. 

The  listing  of  tuples  in  the  data  base  is  given  in 
Appendix  B.  The  queries  in  this  section  are  related  with 
these  values.  Suppose  we  have  a  query  "  Which  systems 
contain  ACC5PR0G  program  ?  ".  The  implementation  of  this 
query  and  the  answer  to  this  query  is  given  in  Fig.  3.3  . 


UFI>  SELECT  ENTITY  NAMEl 

2  FROM  CONTAINS'X 

3  WHERE  ENTITY  NAME2= ' ACC5PR0G '  AND 

4  ENTITY_T YPE 1= ' SYSTEM ' ; 

ENTITY_NAME1 

ACCOUNT- 2 
ACCOUNT- 5 


Figure  3.3  An  Example  of  Query. 

Other  types  of  query  examples  follow  : 

Query  :  "  Who  is  responsible  for  ACCOUNT- 2  system  ?  " 

The  implementation  of  this  query  is  given  in  Fig.  3.4  . 
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UFI>  SELECT  ENTITY  NAMEl 

2  FROM  RESPONSIBLE  FOR 

3  WHERE  ENTITY_NAME2=^ ACCOUNT-2 ' ; 

ENTITY  NAMEl 


JONES  H.B. 
ALLEN  G.M. 
SCOTT  T.L. 


Figure  3.4  An  Example  of  Query. 

Query  :  "  Which  programs  process  PAYROLLS  record  ?  " 

The  implementation  of  this  query  is  given  in  Fig.  3.5  . 


Figure  3.5  An  Example  of  Query. 


Query  :  "  What  elements  are  contained  in  the  PAYROLLS 
record  ?  "  .  The  implementation  of  this  query  is  given  in 
Fig.  3.6  . 


Query  :  "  What  relationships  does  FILE  participate  in  ? 

The  implementation  of  this  query  is  given  in  Fig.  3.7  . 
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Figure  3.6  An  Example  of  Query. 


UFI> 

SELECT  ENTITY  NAME 1. RELATION. ENT I Y  NAME2 

2 

FROM  RELATIONSHIP 

3 

WHERE  ENTITY_NAME 1= ’ FILE ' 

> 

ENTITY_NAME1  RELATION 

ENTITY_NAME2 

FILE 

CONTAINS 

FILE 

FILE 

CONTAINS 

DOCUMENT 

FILE 

CONTAINS 

RECORD 

FILE 

CONTAINS 

ELEMENT 

FILE 

DERIVED  FROM 

FILE 

FILE 

DERIVED“FROM 

DOCUMENT 

FILE 

HAS  SORT  KEY 

ELEMENT 

FILE 

HAS“ACCESS  KEY 

ELEMENT 

8  records  selected. 

Figure  3.7  An  Example  of  Query. 

Query  :  "  What  aliases  ACCOUNT- 2  program  has  ?  "  .  The 
implementation  of  this  query  is  given  in  Fig.  3.8  . 

Query  :  "  Which  entities  are  in  the  C0NTR0L2  category  ? 

"  .  The  implementation  of  this  query  is  given  in  Fig.  3.9  . 

We  are  not  able  to  answer  some  kinds  of  queries  with 
this  dictionary  design.  For  example,  a  query  "  What  kind  of 
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UFI>  SELECT  ALIAS  NAME 

2  FROM  ALIAS  “ 

3  WHERE  ENTITY_NAME1= ' ACCOUNT- 2 ’ ; 

ALIAS_NAME 

AS  EL 
AFRO 


Figure 

3.8  An  Example  of  Query. 

UFI>  SELECT 

ENTITY  NAME. ENTITY  TYPE 

2  FROM  CATEGORY- 

3  WHERE  CATEGORY_NAME= ’ C0NTR0L2 ’ ; 

ENTITY_NAME 

ENTITY_TYPE 

ACCOUNT- 2 

PROGRAM 

ACC5FILE 

FILE  X 

ACC6FILE 

FILE-X 

PAYROLLS 

RECORD 

PAYROLLS 

RECORD 

PAYROLL? 

RECORD 

6  records  selected. 

Figure  3.9  An  Example  of  Query. 

entity  is  PRELEl  ?  "  cannot  be  answered  easily.  To  answer 
this  kind  of  query,  we  have  to  implement  every  data  element 
as  a  separate  entity  in  a  special  relation.  This  implemen¬ 
tation  causes  overhead  in  the  data  base.  Also  a  query  " 
What  entities  appear  in  relationships  but  are  not  defined  as 
a  tuple  in  any  of  the  entity  relations  ?  "  cannot  be 
answered  easily.  For  example  PROCESSES 
(’ACCOUNT-2' , ’PROGRAM’ , 'ACCREC , ’RECORD' )  is  a  tuple  of 
PROCESSES  relation  but  ’ACCREC’  is  not  a  tuple  in  RECORD 
relation.  To  answer  this  kind  of  query,  we  will  have  to 
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insert  data  into  a  separate  relation  for  every  data  element 
we  want  to  represent  in  the  data  base. 

These  types  of  queries  can  be  answered  by  means  of  a 
different  design.  We  can  define  two  relations: 

ENTITY  (entity_name ,  entity_type,  attrl,  attr2, 

. . .  ,attrM  ) 

RELSHIP  (  relname,  entity_namel,  entity_typel, 

entity_name2 ,  entity_type2 ,  attributes  ) 

By  using  these  relations  we  can  answer  the  queries  we  have 
asked  above  like  following  : 

SELECT  entity_type 
FROM  ENTITY 

WHERE  entity_mane  =  *PRELE'; 

SELECT  entity_namel 

FROM  RELSHIP 

WHERE  entity_namel  NOT  IN 

(  SELECT  entity_name  FROM  ENTITY  ); 

This  design  method  also  has  disadvantages.  For  example  in 
the  first  example  we  will  have  null  values  for  some  attri¬ 
butes  of  the  relation. 

F .  USER  MANUAL 

This  user  manual  explains  the  necessary  procedures  to 
use  the  ORACLE  system.  Additional  information  can  be 
obtained  from  the  ORACLE  system  manuals. 

After  entering  the  VAX-VMS  system,  you  will  see  the 
following  on  the  screen: 

$ 

To  start  ORACLE  type  "  ORACLE"  like  following  and  press 
the  RETURN  key  on  the  terminal  : 


$  ORACLE 


Then  type  "  UFI  "  like  following  and  press  the  RETURN 
key  ; 

$  UFI 

After  a  few  seconds  a  message  will  appear  : 

ORACLE  Utilities,  Copyright  (c)  1979,  1980,  1981,  1982, 

RSI 

UFI  Version  3.5  -  on  Mon  Nov  18  15:39:17  1985 

Connecting  to  ORACLE  V  4.2.2  -  Interim  Release 
Enter  user-name  : 

Enter  password  : 

Upon  correctly  entering  the  user-name,  and  password  you 
will  receive  the  following  on  the  screen  : 

UFI> 

Now,  you  are  ready  to  enter  ORACLE  commands  into  the 
system.  When  you  want  to  exit  the  system  type  ”  EXIT  "  like 
following  : 

UFI>  EXIT 

Then  you  will  see  the  following  message  on  the  screen  : 
logged  off  from  ORACLE  $ 

If  you  want  to  log  off  from  VMS  system  type  "  log  "  : 

$  log 

Now,  you  have  logged  off  the  VMS  system  and  you  will  see 
the  following  message  : 

logging  off  the  VAX  780  computer 


1.  Creating  A  Table 

A  table  can  be  created  using  the  CREATE  TABLE 
command.  An  example  of  this  command  is  given  in  Fig.  3.10  . 


UFI>  CREATE  TABLE  CONTAINS  X . 

> 
9 

Table  created. 


C  ENTITY  NAMEl  CHAR 
ENTITY-TYPE 1  CHAR 
ENTITY-NAME2  CHAR 
5  ENTITY-TYPE2  CHAR 
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Figure  3.10  Creating  a  Table. 

2.  Inserting  Data  Into  a  Table 

After  a  table  is  created,  rows  can  be  entered  into 
the  table  using  the  INSERT  command.  An  example  of  this 
command  is  given  in  Fig.  3.11  . 


UFI: 


!■!>  INSERT  INTO  CONTAINS  X. VALUES 
2  ('ACCOUNT- 2’ SYSTEM^, ' ACCS PROG’ , 'PROGRAM' ); 

ENTITY  NAMEl  ENTITY  TYPEl  ENTITY  NAME2  ENTITY  TYPE2 


ACCOUNT- 2  SYSTEM 

1  record  created 


ACC5PR0G 


PROGRAM 


i 


Figure  3.11  Inserting  Data  Into  a  Table. 


3.  Selecting  Data  From  a  Table 

The  SELECT  command  is  used  to  retrieve  data  from  a 
table.  An  example  of  this  command  is  given  in  Fig.  3.12  . 


UFI>  SELECT  ENTITY  NAMEl,  ENTITY  NAME2 
2  FROM  CONTAINS“X  ; 

ENTITY_NAME1  ENTITY_NAME2 

ACCOUNT- 2  '  ACC5PR0G 


Figure  3.12  Selecting  Data  From  a  Table. 

If  we  want  to  select  all  the  columns  we  can  use  an 
asterisk  (  *  )  in  place  of  the  list  of  column  names.  An 
example  is  given  in  Fig.  3.13  .  In  this  example,  all  the 
columns  of  CONTAINS  X  table  will  be  selected. 


UFI>  SELECT  * 

2  FROM  CONTAINS_X  ; 

ENTITY_NAME1  ENTITY_TYPE1  ENTITY_NAME2  ENTITY_TYPE2 
ACCOUNT- 2  SYSTEM  '  ACCSPROG  PROGRAM* 


Figure  3.13  Selecting  Data  From  a  Table. 

4.  Description  of  the  columns  of  a  Table 

The  DESC  command  gives  the  brief  description  of  the 
columns  used  in  a  table.  The  description  returned  will 
contain  columns  for  the  number  of  the  column,  the  maximum 
size  of  numeric  or  formatted  data,  the  type  of  data,  and  the 
name  of  the  column.  An  example  of  this  command  will  be 
given  in  Fig.  3.14  . 


UFI>  DESC  CONTAINS_X  ; 


size 

csize 

type 

name 

15 

1 

1  character 

ENTITY  NAMEl 

15 

1 

1  character 

ENTITY“TYPE1 

15 

1 

1  character 

ENTITY-NAME2 

15 

1 

1  character 

ENTITY“TYPE2 

Figure  3.14  Description  of  Columns  of  a  Table. 
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IV.  DATA  DICTIONARIES  AND  EXPERT  SYSTEMS 


A.  OVERVIEW  OF  EXPERT  SYTEMS 

Expert  systems  are  the  most  significant  development  in 
the  area  of  artificial  intelligence.  Expert  or  knowledge- 
based  systems  are  computer  programs  which  represent  and 
apply  specific  knowledge  to  solve  problems.  Expert  systems 
use  knowledge  that  is  represented  in  computable  form. 

The  rule-based  system  paradigm  is  the  most  popular 
problem  solving  paradigm  used  for  building  expert  systems. 
The  rule-based  system  paradigm  is  built  around  rules.  The 
rules  cover  the  major  situations  in  a  domain  and  consist  of 
an  "if”  part  and  a  "then"  part  : 

Rule(n)  If  condition  1 
condition  2 

• 

condition  n 
then  action  1 
action  2 

action  n 

The  "if"  parts  of  the  rules  consist  of  combinations  of 
known  facts.  The  "then"  parts  specify  new  facts  to  be 
deduced.  We  use  forward  chaining  to  move  from  existing 
conditions  to  desired  actions.  Backward  chaining  hypoth¬ 
esizes  a  conclusion  and  use  the  rules  to  work  backward 
toward  the  facts  which  lead  to  this  conclusion.  [Ref.  6] 

Expert  systems  use  different  methodologies  for  solving 
problems . 


Some  expert  systems  such  as  XCON  use  synthesis  oriented 
forward  chaining.  Others,  such  as  MYCIN  and  PROSPECTOR  use 
analysis  oriented  backward  chaining. 

XCON's  domain  concerns  the  configuration  of  computer 
system  components.  XCON  knows  the  properties  of  component 
types  for  VAX  computers  and  XCON  handles  orders  involving 
these  components.  MYCIN  aids  medical  doctors  in  diagnosing 
blood  and  meningitis  infections  and  in  recommending  antibi¬ 
otic  drug  treatment.  PROSPECTOR  is  used  by  geologists  in 
the  exploration  of  ore  deposits. 

Expert  systems  can  explain  how  and  why  they  do  things, 
and  they  can  estimate  the  quality  of  their  results.  They 
can  also  demonstrate  the  stages  of  the  task  they  have 
performed  as  well  as  any  remaining  parts  to  be  performed. 

An  expert  system  must  demonstrate  efficient  performance 
and  must  find  effective  solutions.  These  two  factors  must 
be  traded  off  in  certain  cases.  Some  expert  systems  make 
good  decisions  but  very  slowly.  Some  decisions,  on  the 
.  other  hand,  require  rapid  response  time,  possibly  at  the 
expense  of  accuracy.  Expert  systems  must  be  built  to 
satisfy  the  particular  requirements  of  each  application 
domain. 

B.  COMPONENTS  OF  EXPERT  SYSTEMS 

The  essential  components  of  an  expert  system  are  the 
following  : 

1.  Language  Processor  :  The  user  and  expert  system  commu¬ 

nicate  with  each  other  by  means  of  a  language  processor. 
The  user  enters  the  commands  or  questions  into  the 
system  by  using  the  language  processor.  Conversely,  the 
information  generated  by  the  system  is  presented  to  the 
user  via  the  same  mechanism. 

2.  Blackboard  :  Intermediate  decisions  are  recorded  in  a 

blackboard.  Generally,  blackboards  record  three  types 
of  decisions  :  plan,  agenda,  and  solution.  Plan  recom¬ 
mends  a  general  solution  methodology  to  the  problem. 


Agenda  records  the  actions  awaiting  the  execution.  The 
decisions  and  hypotheses  about  the  problem  are  repre¬ 
sented  by  solution  elements. 

3.  Scheduler  :  The  control  of  the  agenda  and  the  control 

of  the  order  of  the  rule  processing  are  maintained  by  a 
scheduler. 

4.  Interpreter  :  The  rules  contained  in  the  knowledge  base 
get  applied  to  the  agenda  items  by  the  interpreter. 

5.  Consistency  enforcer  :  When  new  data  are  introduced, 

the  consistency  enforcer  adjusts  the  previous  solutions 
to  the  new  data  base. 

6.  Justifier  :  By  using  general  types  of  question/ 

answering  plans,  the  justifier  explains  the  system's 
behaviour  to  the  user. 

7.  Knowledge  base  :  The  facts  and  information  about  the 

problem  and  problem  solving  rules  are  recorded  in  the 
knowledge  base.  [Ref.  7] 

The  components  of  expert  systems  are  given  in  Fig.  4.1  . 

C.  EXPERT  SYSTEMS  AND  CONVENTIONAL  DATA  PROCESSING  SYSTEMS 
There  are  many  ways  in  which  expert  systems  differ  from 
both  data  processing  systems  and  other  AI  systems. 

AI  systems  involve  several  features  such  as  symbolic 
representation,  symbolic  inference,  and  heuristic  search. 
AI  systems  use  one  of  several  formal  approaches  developed 
for  these  features.  For  example,  one  way  to  show  what  a  set 
of  antecedent -consequent  rules  can  do  is,  to  draw  a  network 
showing  how  the  facts  that  are  the  consequents  of  one  rule 
serve  as  antecedents  to  the  next.  This  network  is  called  an 
inference  net  in  AI  systems. 

Expert  systems  perform  their  tasks  in  decision  making 
environments.  They  solve  problems  in  narrow  and  specialized 
domains.  In  contrast,  the  other  AI  systems  use  more  general 
methods . 

Expert  systems  contain  self-knowledge,  that  is  knowledge 
about  its  own  structure  and  operation.  By  using 
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Figure  4.1  Components  of  an  Expert  System. 


self-knowledge,  expert  systems  provide  explanations  and 
justifications  about  their  conclusions.  This  knowledge  is 
also  used  for  modification  and  reorganization  of  the  system. 

Expert  systems  solve  problems  in  several  areas  which  can 
be  categorized  as  follows  : 

1.  Interpretation  systems  :  signal  interpretation,  speech 

understanding  chemical  structure  elucidation. 

2.  Prediction  system  :  weather  forecasting,  crop 

estimation. 

3.  Diagnosis  systems  :  medical,  electronic,  software 

diagnosis . 

4.  Design  systems  :  building  design,  budgeting. 


software 
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5.  Planning  systems  :  robot,  project,  communication, 

military  planning  problems. 

6.  Monitoring  systems  :  nuclear  power  plant,  air  traffic, 

disease,  fiscal  management  tasks. 

7.  Debugging  systems  :  computer  aided  debugging  systems. 

8.  Repair  systems  :  automotive,  network,  avionic  systems. 

9.  Instruction  systems  :  Diagnose  of  students  behaviors. 

10.  Control  systems  :  air  traffic  control , mission  control, 
business  management. 

D.  KNOWLEDGE  REPRESENTATION 

There  are  many  different  kinds  of  knowledge.  Basically, 
knowledge  can  be  represented  by  facts  and  procedures.  Facts 
are  things  that  are  true  about  the  world,  and  correspond  to 
the  meanings  of  nouns  and  adjectives.  Procedures  are 
sequences  of  actions  that  do  things  and  correspond  to  the 
meanings  of  verbs.  There  are  many  different  ways  of 
representing  and  manipulating  knowledge  by  computer. 

1.  Predicate  Calculus 

Predicate  calculus  is  one  of  the  widely  used  forms 
of  knowledge  representation.  The  syntax  of  symbols  repre¬ 
senting  knowledge  consists  of  terms  and  predicate  symbols. 
In  predicate  calculus  logical  connections  between  entities 
and  functions  can  be  easily  represented.  Predicate  calculus 
can  also  express  sentences  involving  universal  quantifiers 
and  existential  quantifiers.  In  predicate  calculus,  new 
symbol  structures  can  be  created  from  old  ones  by  using 
rules  of  inference.  Predicate  calculus  can  express  the 
sentence  "All  parts  are  large  "  as 


(  ALL  (x)  (  (  IS_A  X  PART  )  - >  (  LARGE  x  )  )  ) 


2 .  Semantic  Networks 

Many  knowledge  representations  are  built  around  some 
form  of  semantic  net.  The  syntax  of  a  semantic  net  consists 
of  objects  and  relationships  between  pairs  of  objects.  In 
semantic  nets,  the  objects  are  represented  by  labeled 
circles  and  the  relations  are  represented  by  labeled  arrows. 
The  semantic  nets  have  a  restriction  in  that  they  only  work 
well  for  predicates  of  two  arguments. 

3 .  Control  Structures 

1.  Unordered  Control  Structures  :  In  a  rule  based 
system  a  set  of  antecedent- consequent  rules  can  be  repre¬ 
sented  by  a  network.  By  using  AND/OR/NOT  trees  this  network 
can  be  represented.  Facts  are  then  input  to  this  system. 
An  AND/OR/NOT  tree  reaches  from  base  facts  at  the  bottom, 
through  antecedent -consequent  rules,  to  possible  conclusion 
at  the  top. 

2.  Backwards  Chaining  Control  Structures  ;  This 
structure  imposes  a  single  sequential  ordering  on  everything 
that  happens.  Backwards  chaining  starts  with  a  hypothesized 
conclusion  and  uses  rules  to  work  backward  toward  the  facts 
that  support  the  hypothesis.  Backwards  chaining  works  well 
whenever  there  are  many  more  facts  than  goals. 

3.  Forward  Chaining  Control  Structures  :  In  some 
systems,  there  are  many  possible  conclusions  but  just  a  few 
facts.  For  these  situations  forward  chaining  is  used  by 
starting  with  the  facts  and  reasoning  to  conclusions. 

E.  METAKNOWLEDGE 

Metaknowledge  can  be  very  important  to  building, 
running,  and  modifying  expert  systems.  Performance  can  be 
improved  by  supplying  various  sets  of  metaknowledge  that  is 
knowledge  about  the  knowledge  in  the  system. 

Metaknowledge  guides  the  location  and  selection  of 
rules.  It  records  needed  facts  about  knowledge. 
Metaknowledge  enhances  the  system’s  explanation  abilities  by 
justifying  rules. 


It  facilitates  the  entry  of  new  teirms,  facts,  and  heuristic 
rules . 

Information  resource  management  is  a  potential  domain 
for  the  implementation  of  expert  systems.  Data  dictionary- 
systems  are  currently  used  for  representing  metaknowledge 
about  organizational  information  resources.  Especially, 
extensibility  features  of  data  dictionary  systems  make  it 
easy  to  define  new  data  types  and  relationships  to  represent 
metaknowledge . 

Information  resource  management  data  contains  informa¬ 
tion  necessary  to  manage  and  control  the  data.  This  type  of 
data  includes  rules  for  performing  its  function.  The  rules 
are  the  functions  to  be  performed  by  the  system  relative  to 
data.  The  rules  are  very  important  in  information  resource 
management,  because,  they  insure  effective  management 
control  of  data.  These  rules  guide  the  data  base  activities 
and  provide  information  about  data. 

We  can  store  facts  about  information  resources  using 
data  dictionary  systems,  but  current  data  dictionary  systems 
are  unable  to  accommodate  rules.  Logic-oriented  language 
Prolog  can  be  used  to  implement  these  rules.  Prolog  allows 
user  to  define  rules  which  are  more  compact  than  a  list  of 
facts . 

F.  KNOWLEDGE  REPRESENTATION  IN  PROLOG 

The  declarative,  logic-based  language  Prolog  is  used  for 
solving  problems  that  involve  objects  and  relationships 
between  objects.  The  Prolog  programmer  asks  what  formal 
relationships  and  objects  occur  in  the  problem,  and  what 
relationships  are  true  about  the  desired  solution. 

Programming  in  Prolog  consists  of  declaring  some  facts 
about  objects  and  their  relationships;  defining  some  rules 
about  objects  and  their  relationships  and  then  asking  ques¬ 
tions  about  objects  and  their  relationships  subject  to  these 
rules.  [Ref.  8] 


An  explanation  of  an  implementation  of  facts,  rules,  and 
a  query  will  be  explained  with  the  following  example. 
Suppose  we  have  relations  : 

male(gerry ) . 

male (John) . 

female (mary) . 

female (cindy) . 

parents(gerry ,betty ,mike) . 

parents (mary , bet ty, mike) . 

brother_of (X,Y) : -male(X) , parents (X,M,F) , 

parents (Y,M,F) . 

Suppose  we  want  to  know  if  Gerry  is  the  brother  of 
anyone.  We  can  ask  this  question  in  Prolog  like  this  : 

?-brother_of (gerry ,X) . 

Prolog  prints  X=  mary.  as  an  answer  to  this  question. 

G.  A  PROLOG  MODEL  OF  A  SIMPLE  DATA  DICTIONARY 

The  system- standard  schema  of  the  dictionary  is  defined 
as  a  specific  set  of  entity-types ,  relationship  types,  and 
attribute  types.  This  system- standard  schema  satisfies  the 
requirements  of  many  IRDS  environments.  Also,  this  schema 
is  a  standard  schema  developed  by  the  National  Bureau  of 
Standards . 

Data  dictionary  entity- types ,  relationship  types,  and 

attribute  types  are  as  shown  in  Tables  V  and  VI  . 

Using  Prolog,  implementation  of  a  data  dictionary  with 
the  above  entity- types  and  attribute  types  can  be  repre¬ 
sented  as  predicates.  For  example  we  can  represent  the 
SYSTEM  entity- type  as  : 

sy stem (name, descript ion, date_created, classification, 

last_modif ied_by ,number_of_programs ) . 

Integrity  constraints  can  be  easily  implemented  by  using 
predicates  involving  relationships. 


TABLE  V 

ENTITY-TYPES  AND  ATTRIBUTE-TYPES  OF  DICTIONARY  MODEL 


ENTITY- TYPES  : 

uiER . 

SYSTEM 

PROGRAM 

MODULE 

FILE 

DOCUMENT 

RECORD 

ELEMENT 

BIT  STRING 

CHARACTER  STRING 

FIXED  POINT 

FLOAT" 


ATTRIBUTE -TYPES  : 

ADDED  BY 

CLASSTFICATION 

COMMENTS 

DATE  ADDED 

DESCRIPTION 

IDENTIFICATION  NAME 

LAST  MODIFICATION  DATE 

LAST-MODIFIED  BY  " 

NUMBER  OF  MODIFICATIONS 

NUMBER-OF-RECORDS 

NUMBER-OF-CATEGORY 

NUMBER-OF-PROGRAMS 

DATE  CREATED 

LOCATION 

STANDARD  FOR 

HAS  SORT-REY 

HAS'ACCESS  KEY 


The  general  format  of  these  predicates  are  represented  as  : 

relation(entitynamel , ent itytypel , entitynameZ , entitytypeZ ) . 

We  can  represent  "contains”  relation  in  Prolog  as  : 

contains (sy St em_x,sy St em_t ,program_x,program_t ) . 
contains (program_x,program_t ,module_x,module_t ) . 


contains (module_x,module_t , record_x, record_t ) . 

contains  (record_x ,  record_t ,  eleinent_x ,  elenient_t ) . 

The  other  types  of  relationships  can  be  represented  as 
followings  : 

processes ( system_x , system_t , f ile_x, f ile_t ) . 
responsible_f or (user_x ,user_t , system_x , system_t ) . 
runs (user_x,user_t , system_x, systeiii_t )  . 
goes_to (system_x , system_t , system_x , system_t ) . 

,  derived_froin(document_x,document_t  ,file_x,file_t)  . 
calls (program_x,program_t ,module_x,module_t ) . 
represented_as (element_x,element_t ,bit_string_x, 

bit_string_t ) . 

standard_f or (element_x , element_t , element_x , element_t ) . 
has_sort_key  ( f ile_x ,  f  ile_t ,  element_x ,  eleinent_t ) . 
has_access_key (file_x, f ile_t ,key_x,key_t ) . 

In  Prolog,  rules  are  used  when  we  want  to  say  that  a 
fact  depends  on  a  group  of  other  facts.  A  rule  is  a  general 
statement  about  objects  and  their  relationships. 

We  can  represent  queries  and  information  about  the  data 
base  by  using  Prolog  rules. 

A  relation  in  the  data  base  can  be  derived  from  a  rule 
in  Prolog.  By  using  the  relationship  predicates  we  can 
build  rules  as  followings  : 

contains(X,XX,Z,ZZ) : -contains (X,XX,Y,YY) , 

contains (Y,YY,Z,ZZ) . 

processes (X, XX, Z,ZZ) : -contains (X, XX, Y,YY) , 

processes (Y,YY,Z,ZZ) . 

calls (X, XX,Z,ZZ) ; -contains (X, XX, Y,YY) , calls (Y,YY,Z,ZZ) . 

Implementation  of  queries  in  Prolog  will  be  explained 
with  the  following  examples: 

Suppose  we  have  following  facts  and  rules  about  Data 
Dictionary  : 


contains  ( sys t em_l ,  sys tem_t , prograin_a , program_t ) . 
contains  ( sy  s  t  ein_l ,  sy  s  tem_t ,  program_b ,  program_t ) , 
contains (system_l,system_t  ,prograni_c,program_t )  . 
contains (program_l,program_t ,module_a,module_t ) . 
contains  (prograin_l , program_t , module_b  ,module_t ) . 
contains (program_l,program_t ,module_c ,module_t ) . 
contains (program_l ,program_t ,module_d ,module_t ) . 
contains (file_l , f ile_t ,document_l ,document_t ) . 
contains ( f ile_l , f ile_t , document_2 , document_t ) . 
contains ( f ile_l , f ile_t , document_3 . document_t ) . 

processes (user_l ,user_t , f ile_l , f ile_t ) . 
processes (user_l ,user_t , f ile_2 , f ile_t ) . 
processes (user_2 ,user_t , f ile_l , f ile_t ) . 
processes (user_2 ,user_t , file_2. file_t ) . 

responsible_for(user_l,user_t ,system_l,system_t ) . 
responsible_for(user_l,user_t , system_2 , systeni__t ) . 
responsible_for (user_l,user_t , system_3 . system_t ) . 
responsible_f or (user_2 ,user_t , system_l , system_t ) . 
responsible_for (user_2 ,user_t , system_2 , system^t ) . 

Suppose  we  have  a  query  :  "Which  systems  contain 

program_a  ?"  The  implementation  of  this  query  and  the 
answer  to  this  query  will  be  as  following  : 

?-  contains (X, sys tem_t ,program_a,program_t ) . 

X=  system_l; 

X=  system_2; 
no 

The  other  type  of  query  examples  are  the  following  : 

?-  contains (program_l,program_t,X,module_t) . 

X=  module_a; 


X=  module_b; 

X=  module_c; 

X=  module_d; 
no 

?-  processes(X,user_t ,file_2,file_t) . 

X=  user_l; 

X=  user_2; 
no 

?-  responsible_for(user_l,user_t ,X,system_t) . 
X=  system_l; 

X=  system_2; 

X=  system_3 ; 
no 


?-  processes (X,user_t ,Y, file_t ) . 
X=  user_l,  Y=  file_l; 

X=  user_l,  Y=  file_2; 

X=  user_2,  Y=  file_l; 

X=  user_2,  Y=  file_2; 


no 


We  can  also  define  rules  about  data  base  and 
questions  about  these  rules  : 

contains (file_l , file_t ,record_a, record_t ) . 
contains ( f ile_l , f ile_t , record_b , record_t ) . 
processes ( system_l , system_t , f ile_l , f ile_t ) . 
processes (X, XX, Z,ZZ) : ‘processes(X,XX,Y,YY) , 

contains ( Y , YY , Z , ZZ ) . 
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"What  does  system_l 


We  can  ask  a  question  like  this  : 
processes  ?" 

A  query  related  with  the  above  rule  and  the  answer  to 
this  query  will  be  as  following  : 


?-  processes(system_l,system_t ,X,XX) . 

X=  file_l,  XX=  file_t; 

X=  record_a,  XX=  record_t; 

X=  record_b,  XX=  record_t; 
no 

If  we  want  to  know  the  records  which  are  processed  by 
systeni_l,  we  can  ask  following-  question  : 


?-  processes (system_l,system_t,X,record_t) . 

X=  record_a ; 

X=  record_b; 
no 

This  dictionary  model  is  self-descriptive.  That  is,  we 
can  represent  the  dictionary  entities  which  participate  in  a 
specific  relationship.  The  following  facts  are  used  for 
this  purpose  : 

processes (user_x , entity_t , f ile_x , entity_t ) . 
processes (user_x,entity_t ,document_x,entity_t ) . 
processes (user_x , entity_t , record_x , ent ity_t ) . 
processes (user_x,entity_t ,element_x,entity_t ) . 

processes (system_x, entity_t ,file_x,entity_t) . 
processes (system_x, ent ity_t ,document_x, ent ity_t ) . 
processes (system_x, ent ity_t ,record_x, ent ity_t) . 
processes (system_x , entity_t , element_x , entity_t ) . 

processes (program_x, entity _t ,file_x, ent ity_t) . 
processes (program_x , ent ity_t , document_x , entity_t ) . 


processes (program_x , ent ity_t , record_x , entity_t ) . 
processes (program_x , entity_t , element_x , ent ity_t ) . 

processes (module_x, entity_t , f ile_x , entity_t ) . 
processes(modul e_x , ent i t y_t , do  cument _x , ent i t y_t ) . 
processes  (inodule_x , ent ity_t , record_x , ent ity_t ) . 
processes (module_x , entity_t , element_x , ent ity_t ) . 

runs (user_x , entity_t , system_x, entity_t ) . 
runs ( us  er_x , ent ity_t , program_x , ent i ty_t ) . 
runs (user_x, entity_t ,module_x , entity_t ) . 

Now,  we  can  ask  "  Which  entities  can  participate  in  the 
'process'  relationship  ?  "  by  : 

?-  processes (X,entity_t,Y,entity_t) . 

Prolog  lists  all  the  entities  which  participate  this 
relationship  as  : 

X=  user_x,  Y=  file_x; 

X=  user_x,  Y=  document_x; 

X=  user_x,  Y=  record_x; 

X=  user_x,  Y=  eleraent_x; 


x= 

system_x, 

Y= 

file_x; 

x= 

system_x, 

Y= 

document_x; 

x= 

systein_x, 

Y= 

record_x; 

x= 

system_x. 

Y= 

element_x; 

x= 

program_x 

.  Y= 

file_x; 

x= 

program_x 

,  Y= 

do cument _x 

x= 

prograin_x 

,  Y= 

record_x; 

x= 

program_x 

,  Y= 

element_x; 

x= 

module_x, 

Y= 

file_x; 

x= 

inodule_x. 

Y= 

do cument _x; 

x= 

module_x, 

Y= 

record_x; 

x= 

module_x, 

Y= 

eleraent_x; 

no 
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As  a  second  example,  we  can  ask  Which  entities  can 
participate  in  the  'runs'  relationship  ?  "  by  : 

?-  runs(X,entity_t ,y,entity_t ) . 

X=  user_x,  Y=  system_x; 

X=  user_x,  Y=  program_x; 

X=  user_x,  Y=  module_x; 

Prolog  rules  help  programmers  to  modularize  knowledge. 
It's  a  way  of  creating  new  predicates  from  old  predicates 
without  specifying  facts  explicitly.  The  representation  of 
facts  could  become  tedious,  especially  if  there  are  hundreds 
of  facts  about  the  same  subject.  By  using  rules,  we  can 
represent  all  of  these  facts  easily  since  the  rules  are  more 
compact  than  a  list  of  facts.  Thus,  the  rules  save  a  great 
deal  of  data  entry  effort.  Prolog  makes  it  easy  to  represent 
indirect  relationships.  Prolog  creates  arbitrary  data 
structures  by  means  of  rules  which  are  themselves  data. 
Prolog  offers  a  wide  variety  of  queries.  In  the  structure 
of  Prolog  program  there  are  precise  representations  for 
these  queries.  Prolog  offers  a  great  extensibility  in 
declaring  new  facts  and  rules  about  the  data  base. 


V.  CONCLUSIONS 


This  thesis  has  explained  the  importance  of  metadata  and 
data  dictionary  systems  in  the  management  and  control  of  the 
enterprise’s  data  resource.  It  has  shown  that  the  data 
dictionary  system  is  a  central  repository  of  information 
which  helps  improve  communication  between  system  components 
of  an  enterprise. 

This  thesis  has  surveyed  seven  commercially  avr^.ilable 
data  dictionary  systems.  It  has  explained  the  characteris¬ 
tics  and  the  capabilities  of  these  systems.  Thus,  the 
reader  can  obtain  information  about  these  dictionary 
systems,  compare  them,  and  investigate  the  needed 
requirements  for  a  new  dictionary  system. 

This  thesis  has  developed  a  relational  data  dictionary 
model  which  was  implemented  on  the  ORACLE  relational  data¬ 
base  management  system.  This  dictionary  model  is  capable  of 
satisfying  the  requirements  of  many  IRDS  environments. 
Although  the  relational  model  is  the  most  popular  data  model 
and  it  has  come  to  be  of  great  practical  significance,  its 
dictionary  capabilities  are  limited. 

The  ORACLE  implementation  of  the  data  dictionary  model 
is  capable  of  representing  entity- types  and  relationship- 
types  between  these  entities.  But,  it  is  not  capable  of 
representing  rules  about  information  resource  management 
data.  Since  information  management  data  must  contain  rules 
for  its  operational  purposes,  this  is  a  shortcoming  of 
relational  data  dictionary  models. 

This  thesis  has  explained  the  general  characteristics  of 
expert  systems.  It  has  proposed  a  Prolog  model  of  a  data 
dictionary  as  an  expert  system.  Using  logic-oriented 
language  Prolog,  the  rules  about  the  information  resource 
management  data  can  be  implemented  easily.  This  model  shows 
that  logic  programming  is  suitable  for  relational  database 


applications.  Thus,  the  user  can  save  a  great  deal  of  data 
entry  effort  by  using  rules  instead  of  representing  data 
explicitly.  Prolog  representation  of  data  provides  flexible 
extensibility  features  especially  when  adding  new  data  into 
the  database.  Since  Prolog  is  primarily  a  prototype  tool, 
however,  this  suggests  that  more  research  needs  to  be  done 
concerning  the  efficient  implementation  of  rules  in  a 
relational  environment. 


APPENDIX  A 

ORACLE  TABLES  OF  ENTITY-TYPES  AND  RELATIONSHIP -TYPES 

TABLE  USER  X 

USER_NAME  CHAR  (15)  NOT  NULL, 

DESCRIPTION  CHAR  (60), 

CLASSIFICATION  CHAR  (10), 

DATE_ADDED  CHAR  (10), 

ADDED_BY  CHAR  (15), 

LAST_MODIFICATION_DATE  DATE, 

LAST_MODIFIED_BY  CHAR  (15), 

NUMBER_OF_MODIFICATIONS  NUMBER, 

LOCATION  CHAR (15), 

COMMENTS  CHAR  (45), 

SECURITY  CHAR  (10); 

TABLE  SYSTEM 

SYSTEM_NAME  CHAR  (10)  NOT  NULL, 

DESCRIPTION  CHAR  (60), 

CLASS -FICATION  CHAR  (10), 

DATE_ADDED  DATE, 

ADDED_BY  CHAR  (15), 

LAST_MODIFICATION_DATE  DATE, 

LAST_MODIFIED_BY  CHAR  (15), 

NUMBER_OF_MODIFICATIONS  NUMBER, 

LOCATION  CHAR  (15), 

DURATION_VALUE  NUMBER, 

DURATION_TYPE  CHAR  (10), 

COMMENTS  CHAR  (45), 

SECURITY  CHAR  (10); 

TABLE  PROGRAM 

PROGRAM_NAME  CHAR  (10)  NOT  NULL, 

DESCRIPTION  CHAR  (60), 


NUMBER_OF_LINES_OF_CODE  NUMBER, 
CLASSIFICATION  CHAR  (10), 
DATE_ADDED  DATE, 

ADDED_BY  CHAR  (15), 
LAST_MODIFICATION_DATE  DATE, 
LAST_MODIFIED_BY  CHAR  (15), 
NUMBER_OF_MODIFICATIONS  NUMBER, 
LOCATION  CHAR  (15), 
DURATION_VALUE  NUMBER, 
DURATION_TYPE  CHAR  (10), 
COMMENTS  CHAR  (45), 

SECURITY  CHAR  (10); 

TABLE  MODULE 

MODULE_NAME  CHAR  (10)  NOT  NULL, 
DESCRIPTION  CHAR  (60), 
CLASSIFICATION  CHAR  (10), 
DATE_ADDED  DATE, 

ADDED_BY  CHAR  (15), 
LAST_MODIFICATION_DATE  DATE, 
LAST_MODIFIED_BY  CHAR  (15), 
LOCATION  CHAR  (15), 
NUMBER_OF_LINES_OF_CODE  NUMBER, 
NUMBER_OF_MODIFICATIONS  NUMBER, 
COMMENTS  CHAR  (45), 

SECURITY  CHAR  (10); 

TABLE  FILE  X 

FILE_NAME  CHAR  (10)  NOT  NULL, 
DESCRIPTION  CHAR  (60), 
CLASSIFICATION  CHAR  (10), 
DATE_ADDED  DATE, 

ADDED_BY  CHAR  (15), 
LAST_MODIFICATION_DATE  DATE, 
LAST_MODIFIED_BY  CHAR  (15), 
LOCATION  CHAR  (15), 


NUMBER_OF_MODIFICATIONS  NUMBER, 
NUMBER_OF_RECORDS  NUMBER, 

COMMENTS  CHAR  (45), 

SECURITY  CHAR  (10); 

TABLE  DOCUMENT 

DOCUMENT_NAME  CHAR  (10)  NOT  NULL, 
DESCRIPTION  CHAR  (60), 
CLASSIFICATION  CHAR  (10), 
DATE_ADDED  DATE, 

ADDED_BY  CHAR  (15), 
LAST_MODIFICATION_DATE  DATE, 
LAST_MODIFIED_BY  CHAR  (15), 
LOCATION  CHAR  (15), 
NUMBER_OF_MODIFI CATIONS  NUMBER, 
COMMENTS  CHAR  (45), 

SECURITY  CHAR  (10); 

TABLE  RECORD 

RECORD_NAME  CHAR  (10)  NOT  NULL, 
DESCRIPTION  CHAR  (60), 
CLASSIFICATION  CHAR  (10), 
DATE_ADDED  DATE, 

ADDED_BY  CHAR  (15), 
LAST_MODIFICATION_DATE  DATE, 
LAST_MODIFIED_BY  CHAR  (15), 
NUMBER_OF_MODIFICATIONS  NUMBER, 
RECORD_CATEGORY  CHAR  (10), 
COMMENTS  CHAR  (45), 

SECURITY  CHAR  (10); 

TABLE  ELEMENT 

ELEMENT_NAME  CHAR  (10)  NOT  NULL, 
DESCRIPTION  CHAR  (60), 
CLASSIFICATION  CHAR  (10), 
DATE_ADDED  DATE, 

ADDED_BY  CHAR  (15), 
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LAST_MODIFICATION_DATE  DATE, 
LAST_MODIFIED_BY  CHAR  (15), 
NUMBER_OF_MODIFICATIONS  NUMBER, 
ALLOWABLE_RANGE  NUMBER, 
ALLOWABLE_VALUE  NUMBER, 

COMMENTS  CHAR  (45), 
CODE_LIST_LOCATION  CHAR  (15), 
DATA_CLASS  CHAR  (10), 

SECURITY  CHAR  (10); 

TABLE  CONTAINS  X 

ENTITY_NAME1  CHAR  (15), 
ENTITY_TYPE1  CHAR  (15), 
ENTITY_NAME2  CHAR  (15), 
ENTITY_TYPE2  CHAR  (15); 

TABLE  PROCESSES 

ENTITY_NAME1  CHAR  (15), 
ENTITY_TYPE1  CHAR  (15), 
ENTITY_NAME2  CHAR  (15), 
ENTITY_TYPE2  CHAR  (15); 

TABLE  RESPONSIBLE  FOR 

ENTITY__NAME1  CHAR  (15), 
ENTITY_TYPE1  CHAR  (15), 
ENTITY_NAME2  CHAR  (15), 
ENTITY_TYPE2  CHAR  (15); 

TABLE  RUNS 

ENTITY_NAME1  CHAR  (15), 
ENTITY_TYPE1  CHAR  (15), 
ENTITY_NAME2  CHAR  (15), 
ENTITY_TYPE2  CHAR  (15); 

TABLE  GOES  TO 

ENTITY_NAME1  CHAR  (15), 
ENTITY_TYPE1  CHAR  (15), 
ENTITY_NAME2  CHAR  (15), 


ENTITY_TYPE2  CHAR  (15); 


TABLE  DERIVED  FROM 


ENTITY_NAME1 

CHAR 

(15), 

ENTITY_TYPE1 

CHAR 

(15), 

ENTITY_NAME2 

CHAR 

(15), 

ENTITY_TYPE2 

CHAR 

(15); 

TABLE  CALLS 

ENTITY_NAME1 

CHAR 

(15), 

ENTITY_TYPE1 

CHAR 

(15), 

ENTITY_NAME2 

CHAR 

(15), 

ENTITY_TYPE2 

CHAR 

(15); 

TABLE  REPRESENTED  AS 

ENTITY_NAME1 

CHAR 

(15), 

ENTITY_TYPE1 

CHAR 

(15), 

ENTITY_NAME2 

CHAR 

(15), 

ENTITY_TYPE2 

CHAR 

(15); 

TABLE  STANDARD  FOR 

ENTITY_NAME1 

CHAR 

(15), 

ENTITY_TYPE1 

CHAR 

(15), 

ENTITY_NAME2 

CHAR 

(15), 

ENTITY_TYPE2 

CHAR 

(15); 

TABLE  HAS  SORT  KEY 

ENTITY_NAME1 

CHAR 

(15), 

ENTITY_TYPE1 

CHAR 

(15), 

ENTITY_NAME2 

CHAR 

(15), 

ENTITY_TYPE2 

CHAR 

(15); 

TABLE  HAS  ACCESS  KEY 


ENTITY_NAME1  CHAR  (15), 
ENTITY_TYPE1  CHAR  (15), 
ENTITY_NAME2  CHAR  (15), 
ENTITY  TYPE2  CHAR  (15); 


TABLE  ALIAS 
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ENTITY_NAME  CHAR  (15), 
ENTITY_TYPE  CHAR  (15), 
ALIAS_NAME  CHAR  ( 15 ) ; 

TABLE  CATEGORY 

ENTITY_NAME  CHAR  (15), 
ENTITY_TYPE  CHAR  (15), 
CATEGORY_NAME  CHAR  (15); 

TABLE  RELATIONSHIP 

ENTITY_NAME1  CHAR  (15), 
ENTITY_TYPE1  CHAR  (15), 
ENTITY_NAME2  CHAR  (15), 
ENTITY_TYPE2  CHAR  (15), 

RELATION  CHAR  (15); 

TABLE  ENTITY 

ENTITY_NAME  CHAR  (15)  NOT  NULL, 
DESCRIPTION  CHAR  (60), 
CLASSIFICATION  CHAR  (10), 
DATE_ADDED  DATE, 

ADDED_BY  CHAR  (15), 
LAST_MODIFICATION_DATE  DATE, 
LAST_MODIFIED_BY  CHAR  (15), 
NUMBER_OF_MODIFICATIONS  NUMBER, 
LOCATION  CHAR  (15), 

COMMENTS  CHAR  (45), 

SECURITY  CHAR  (10); 
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